NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/misc-part1/544

Internet Message Format | 1996-08-05 | 4.2 KB

Path: sourcery.han.de!not-for-mail
Newsgroups: comp.sys.amiga.misc
References: <[e-mail]> <4b3h9s$[e-mail]> <[e-mail]> <4b7i18$[e-mail]> <[e-mail]>
From: "Olaf Barthel" <[e-mail]>
Date: Sun, 07 Jan 1996 11:58:05 +0100
X-NewsReader: IntuiNews 1.3a (7.9.95)
Subject: Re: OS features
Message-ID: <[e-mail]>

In Article <[e-mail]>, Steve Koren <[e-mail]> wrote:
>
> Someone wrote:
>
> > >Memory protection is one, is it really worth the added overhead? I
>
> IMHO, yes, it is 100% worth the marginal overhead.  I could mention any
> of a zillion reasons, but here are a few:
>
>   * Right now, one cannot safely do program development on an Ami which
>     has been doing some long-duration background task without risk of
>     crashing the machine and loosing all the work the background task
>     has done.  I do a fair amount of programming, so this is annoying.
>
>   * Even without programming, just running a major app can be dangerous.
>     I feel my Amiga is pretty stable as far as Amigas go, but I often
>     have one reboot necessary per 1-2 weeks (of fairly intensive use).
>     Compare this to my Unix system at work with memory protection that
>     has been up continuously for two *years*.  No crashes, no reboots,
>     no lockups, no nothing.  That is the sort of stability Amigas need
>     to be best suited to business use.
>
> Without protection, you can be tolerably stable for hobbyist use, as the
> Amiga is now, but you're never going to get to the level of stability
> you can get to with memory protection.  I want to be able to safely
> compile and debug my latest program, or try something I downloaded from
> aminet, while I'm 5 hours into a Lightwave render without the major risk
> of crashing the machine.

   The idea to have better protection against rogue tasks sounds
good enough already. I agree that it would be terribly nice to
have memory protection, but as it stands the chances to implement it
without losing overall software compatibility are so low they could
walk through below a closed door.

> > >whole system, but really all that anyone needs to do, is not run
> > >unknown programs when they have something important running. Well
>
> That is necessary, but not sufficient.  Even if I stick to major, well
> know applications which are very stable, such as ImageFX, FinalWriter,
> Lightwave, etc, I still get occasional crashes.  It doesn't happen very
> often, sure, and I usually do take the risk now.  But it *does* happen.
> It is, alas, all too easy to GURU Amigas now.  This was not an issue 8
> or 10 years ago, but these days, very high stability is just expected in
> a modern OS.

   This really calls for a different OS. One idea that has been brought
forward was to come up with a scheme that allows for different processes
to run in different memory spaces, very much like running multiple
AmigaOS sessions on the same machine. That way you can gun an environment
that has crashed and see the other environments survive. But there is a
problem to solve: how to implement shared memory accesses and interprocess
communication without running into the same trouble the original Amiga
shared memory space causes?

> Someone else wrote:
>
> > In other words, don't worry about it.  Virtual memory is good.
>
> Yep, also, virtual memory can fix fragmentation problems that can plague
> Amigas now.  They give you an extra level of indirection that can be
> used to get a single non-fragmented block as big as your available
> space.  I use VMM on the Amiga as much for this as for getting more
> memory.  Without it, even on my 16 Mb machine, I sometimes get into a
> state where I have 12 Mb free but cannot allocate a 3 Mb buffer because
> my largest single fragment is less than that.  With VM, this is not a
> problem.  There may be fragmentation on the physical media, but the MMU
> can make this appear as a single contiguous block to the machine.  If I
> have 20 Mb free, I know I can allocate a single 20 Mb block of memory.

   That's an idea. I have seen similar under BeOS which can put contiguous
memory regions together from fragments.

--
Home: Olaf Barthel, Brabeckstrasse 35, D-30559 Hannover
 Net: [e-mail]